comment

diff --git a/doc/todo/More_fine-grained_testremote_command/comment_1_d0d1406f9b1619b57908e62ac3200f69._comment b/doc/todo/More_fine-grained_testremote_command/comment_1_d0d1406f9b1619b57908e62ac3200f69._comment
new file mode 100644 (file)
index 0000000..8d61f17
--- /dev/null
+++ b/doc/todo/More_fine-grained_testremote_command/comment_1_d0d1406f9b1619b57908e62ac3200f69._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-10-14T14:54:53Z"
+ content="""
+It would be possible to make `git-annex testremote` support the
+command-line options of the underlying test framework (tasty).
+`git-annex test` already does that, so has --list-test and --pattern.
+
+It's not as simple as just plumbing that up though, because testremote has
+implicit dependencies in its test ordering. It has to do the `storeKey`
+test before it can do the `present` test, for example. Those dependencies
+would need to be made explict, rather than implicit.
+
+Explict dependencies, though, would also make it not really possible to run
+most of the tests separately. Running testremote 5 times to run the listed
+tests, if each run does the necessary `storeKey` would add a lot of overhead.
+
+Not declaring dependencies and leaving it up to the user to run testremote
+repeatedly to run a sequence of tests in the necessary order would also
+run into problems with testremote using random test keys which change every
+time it's run, as well as it having an end cleanup stage where it removes
+any lingering test keys from the local repository and the remote.
+
+This seems to be a bit of an impasse... :-/
+"""]]

diff --git a/doc/todo/More_fine-grained_testremote_command/comment_2_de940a1c4ca0194582cd0ad449eefe28._comment b/doc/todo/More_fine-grained_testremote_command/comment_2_de940a1c4ca0194582cd0ad449eefe28._comment
new file mode 100644 (file)
index 0000000..94958c8
--- /dev/null
+++ b/doc/todo/More_fine-grained_testremote_command/comment_2_de940a1c4ca0194582cd0ad449eefe28._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2025-10-14T15:21:02Z"
+ content="""
+I don't know about the "--write-only" name, but I see the value in having a
+way for testremote to check what a remote that is expected to only allow
+read access does not allow any writes, as well as otherwise behaving
+correctly.
+
+There are actually only two write operations, `storeKey` and `removeKey`.
+Since `removeKey` is supposed to succeed when a key is not present, if
+`storeKey` fails, then `removeKey` will succeed. But `removeKey` should
+fail to remove a key that is stored on the remote. To test that,
+the --test-readonly=file option would need to be used to provide a file
+that is already stored on the remote.
+
+I think it would make sense to require that option be present
+in order to use this new "--write-only" (or whatever name) option.
+
+---
+
+Also, git-annex does know internally that some remotes are readonly. For
+example, a regular http git remote that does not use p2phttp.
+Or any remote that has `remote.<name>.annex-readonly` set. Currently
+`testremote` only skips all the write tests for those, rather than
+confirming that writes fail. It would make sense for testremote of a known
+readonly remote to behave as if this new option were provided.
+
+(But, setting `remote.<name>.annex-readonly` rather than using
+the "--write-only" option would not work for you, because that config
+causes git-annex to refuse to try to write to the remote. Which doesn't
+tell you if your server is configured to correctly reject writes.)
+"""]]